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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI). 
The present document is part 6 of a multi-part deliverable. Full details of the entire series can be found in part 1 [2]. 
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Scope 



The present document contains service-specific details for the handover of the lawfully intercepted PSTN/ISDN 
Services (including emulated services such as those defined in ES 282 002 [3]) using packet-based techniques as 
defined in TS 102 232-1 [2]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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ETSI TS 101 671: "Lawful Interception (LI); Handover interface for the lawful interception of 
telecommunications traffic". 



NOTE: Periodically TS 101 671 is published as ES 201 671. A reference to the latest version of the TS as above 
reflects the latest stable content from ETSI/TC LI. 



ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details 
(SSD) for IP delivery; Part 1: Handover specification for IP delivery". 

ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional 
architecture". 

ITU-T Recommendation X.680: "Information technology - Abstract Syntax Notation One 
(ASN.l): Specification of basic notation". 
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ITU-T Recommendation G.711 (1988): "Pulse code modulation (PCM) of voice frequencies". 

IETF RFC 2327: "SDP: Session Description Protocol". 

ETSI TS 187 005: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); NGN Lawful Interception; Lawful interception functional 
entities, information flow and reference points". 

Void. 

IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 102 232-1 [2] and TS 101 671 [1] 
apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ASN.l 

cc 

CIN 
CSP 



Abstract Syntax Notation One 
Content of Communication 
Communications Identity Number 
Communications Service Provider 



NOTE: CSP covers all Access Providers, Network Operators and Service Providers. 

HI1 Handover Interface 1 (for Administrative Information) 

HI2 Handover Interface 2 (for Intercept Related Information) 

HI3 Handover Interface 3 (for Content of Communication) 

IP Internet Protocol 

IRI Intercept Related Information 

ISDN Integrated Services Digital Network 

LEA Law Enforcement Agency 

LEMF Law Enforcement Monitoring Facility 

LI Lawful Interception 

MF Mediation Function (at CSP) 

PDU Protocol Data Unit 

PES PSTN/ISDN Emulation Subsystem 

PSTN Public Switched Telephone Network 

RTP Real-time Transport Protocol 

SDP Session Description Protocol 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UDP User Datagram Protocol 



General 



4.1 Approach 

The present document forms part 6 of the TS 102 232 family of standards, in that it is a service-specific component of 
the TS 102 232-1 [2] framework. 

For ISDN interception TS 101 671 [1] defines the interception behaviour that leads to visible IRI events on the 
handover interface. TR 102 053 (see bibliography) provides detailed guidance in support of TS 101 671 [1]. 

The present document provides a model for handover that may be used in conjunction with the interception domain 
specification TS 187 005 [8]. TS 187 005 [8] also provides an overview of the document structure within the NGN LI 
domain. 
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4.2 



Reference model 




Network Mediation 
Function (MF) 



Handover 
interface 



Law Enforcement 

Monitoring 
Facility (LEMF) 



Figure 1 : Reference model 



Headers, data exchange and networks 



5.1 Approach 



TS 102 232-1 [2] describes a technique for data exchange, and specifies the headers that shall be associated with the 
results of interception. The present document follows TS 102 232-1 [2] regarding headers, data exchange and networks. 



5.2 



Structures 



IRI events from TS 101 671 [1] are sent using the structure ETSI671IRI. Supplementary information IRI (defined in 
clause 6.3) is sent using the structure pstnlsdnlRI (see clause A. 2). CC is sent using the structure pstnlsdnCC 
(see clauses 6.2 and A. 3). 



5.3 



Definition of a communications session 



A new Communications Identity Number (or CIN) is assigned each time a new communications session begins. See 
TS 101 671 [1] for the definition of communications session. 

Typically, a new communications session is defined to begin (i.e. a new CIN is assigned) when each IRI-BEGIN 
message is sent (as listed in TS 101 671 [1]), then all further IRI and CC relating to that session has the same CIN. 
Typically, a REPORT record would form a communications session in its own right. If CC or an IRI record is generated 
for a session before the IRI-BEGIN is sent (e.g. through fault situations, or owing to unexpected latency), the CSP shall 
still ensure that all IRI and CC in the communication session has the same CIN. 



Intercept Related Information (IRI) and Content of 
Communication (CC) 



6.1 



Definition of IRI events and CC events 



IRI events are defined as per TS 101 671 [1]. CC is sent on all occasions that CC would be sent under TS 101 671 [1]. 
Further details for ISDN are provided by the state model and message sequence diagrams in TR 102 053 (see 
bibliography); in particular see clause 6 of TR 102 053. 



6.2 



CC format 



CC shall be expressed as an RTP frame. The CC shall also contain the RTP header, UDP header and IP header, except 
by agreement between CSP and LEA: 

NOTE: CSPs and LEAs may choose to omit headers because they are unavailable at the point of interception. 
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The Supplementarylnfo FrameType field indicates which headers are present in a given CC stream. If all headers are 
present, the FrameType field may be omitted. 

In the case where the RTP header is unavailable, one may be inserted by the mediation function, subject to agreement 
between LEA and CSP. The addition of an inserted RTP header may aid processing the audio stream at the receiver. 

The content (i.e. RTP payload) shall be a complete, unmodified copy of CC information that is part of the target 
communication. 

The RTP header shall accurately describe the target communication. 

The information contained in the IP and UDP header does not necessarily relate to any media flow as seen by the target. 

IP and UDP headers shall not be inserted to the intercepted material by the mediation function if they are unavailable. 

If encryption has been applied within the CSP's domain and under their control, either it shall be removed or full details 
of the encryption including keys shall be supplied. 

Typically under PSTN/ISDN the codec used is ITU-T Recommendation G.71 1 [6], The codec in use shall be signalled 
as described in clause 6.3. 

6.3 Supplementary information 

6.3.1 Requirements for supplementary information 

It is required that the LEA has enough information to decode and comprehend the traffic delivered over the Handover 
Interface. The following information is required: 

• Description of the format of the CC, to allow the LEMF to understand the information within the CC. 

6.3.2 Supplementary information 

Supplementary information is defined to be the following set of information. 



Field name 


Status 


ASN.1 field 


Information 


Media format 


Mandatory 


mediaFormat 


This field signals the codec used, as defined in 
RFC 3551 [10].The supplementary info shall contain only 
one media format (send another supplementary 
information messages if the format changes). 


Media attributes 


Conditional (i.e. 
mandatory 
under the 
conditions 
listed) 


mediaAttributes 


If any extra information (beyond the Media Format) is 
needed to understand the delivered CC then it shall be 
sent here, in the format defined in the a= field of SDP (see 
RFC 2327 [7]). Typically, media attributes shall be present 
if and only if the media format is 32 or above. 


Encryption key 


Conditional 


encryptionKey 


See clause 6.2. 


Session name 


Optional 


sessionName 


If present in the target communication (e.g. SDP 's=' field), 
it may be present in supplementary information as decided 
by national agreement. 


Session 
information 


Optional 


sessionlnfo 


If present in the target communication (e.g. SDP 'i=' field), 
it may be present in the target communication, it may be 
present as decided by national agreement. 


Copy of SDP 
message 


Optional 


copyOf S D PMessage 


In addition to the above information, an SDP message may 
be included here. 



6.3.3 Sending supplementary information 



Supplementary information shall be sent as soon as possible for a communications session, and should be sent before 
CC is available. 



ETSI 



9 ETSI TS 102 232-6 V2.2.1 (2007-05) 

If supplementary information is not available before the CC, under no circumstances shall CC be buffered or delayed. If 
supplementary information is critical to interpreting the CC, then CSPs shall ensure their systems are designed to avoid 
any delay in sending supplementary information. 

If the communications session contains traffic in more than one direction, then one set of supplementary information 
shall be sent for each direction present. Under some circumstances, the traffic sent in one direction will have a different 
set of supplementary information from traffic sent in the other direction (e.g. traffic to the target uses a different codec 
compared to traffic going from the target). Under these circumstances, the direction flag shall always be present and 
correct for all CC PDUs, and only the values 'To Target' and 'From Target' shall be used. 

If the supplementary information changes during a session (e.g. change of codec) then a new set of supplementary 
information shall be sent as IRI as soon as possible (it should be sent before the change occurs). It is required that the 
LEMF can identify the point in the CC stream at which the change took place. If it is not clear from the CC, then the 
CSP should populate the field 'First PDU number' within the structure InformationAppliesTo', to state the sequence 
number of the first CC-PDU to which the new supplementary information applies. 

6.3.4 Identification of CCLinks 

TS 101 671 [1] identifies certain occasions when different CCLinks are established (e.g. multi-party calls). When 
CCLinks are used, the field CCLinkID (see annex A) shall be present and set as described in TS 101 671 [1]. Note that 
the sequence numbering of CC-PDUs is not affected by the CCLink counter (i.e. do not maintain separate sequence 
number counts for separate CCLinks). 

If there are a number of different CCLinks (see TS 101 671 [1]), then one set of supplementary information shall be 
sent for each CC Link. Within each CC Link, traffic in different directions shall be isolated and identified as described 
in clause 6.3.3. 
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Annex A (normative): 
ASN.1 forlRlandCC 

A.1 Note on integrating ASN.1 structures 

IRI information structures are defined by the ASN.1 in TS 101 671 [1]. The headers that shall be applied to all IRI are 
defined in TS 102 232-1 [2]. There is some overlap between these structures, in that some fields which are present in 
TS 101 671 [1] IRI-Parameters are then repeated in the TS 102 232 PSHeader construction. In particular, there are the 
following overlaps: Lawful Intercept Identifier, Communication Identifier, TimeStamp. 

The present document follows TS 102 232-1 [2] for header information and requires that the TS 102 232 header shall be 
populated. For ease of interoperability the present document recommends that repeated fields should be populated in 
both the TS 102 232 and TS 101 671 [1] parts of the header. 



A.2 ASN.1 definitions 

The ASN.1 (ITU-T Recommendation X.680 [4]) module that represents the information in the present document and 
meets all stated requirements is shown below. TR 102 503 (see bibliography) gives an overview of the relevant Object 
Identifiers (OID) used in ASN.1 modules of the Lawful Intercept specifications and points to the specification where 
the modules can be found. 



— Description of the Pstnlsdn PDU 

PstnlsdnPDU 

{itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2 ) li-ps{5) 
pstnlsdn (6) version2{2)} 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

IMPORTS 

— from TS 101 671 [1] 
IPAddress 

FROM HI20perations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi2(l) 
versionlO (10) } 

— from TS 102 232-01 [2] 
PayloadDirection 

FROM LI-PS-PDU 

{itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2 ) lawfullntercept (2) li-ps{5) 
genHeader(l) version6 (6) } ; 



Object Identifier Definition 



— definitions are relative to 

— (itu-t(O) identif ied-organization (4) etsi(O) securityDomain (2) lawfulintercept (2) 
pstnlsdnlRIObjId RELATIVE-OID ::= (li-ps(5) pstnlsdn(6) version2(2) iRI(l)} 
pstnlsdnCCObjId RELATIVE-OID ::= (li-ps(5) pstnlsdn(6) version2(2) cC(2)} 
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Description of the Pstnlsdn IRI 



PstnlsdnlRI 



: := SEQUENCE 



pstnlsdnlRIObjId 

pstnlsdnlRIContents 



[0] RELATIVE-OID, 

[1] PstnlsdnlRIContents 



PstnlsdnlRIContents : 

{ 

supplementary Info 



CHOICE 



[0] Supplementarylnfo, 



Supplementary Info 




:= SEQUENCE 




informationAppliesTo 


[0] InformationAppliesTo, 


— Identifies the PDUs to whic 


h this info applies 


mediaFormat 




[1] INTEGER (0. . 127) , 


— As defined in 


RFC 3551 [10] 




mediaAttributes 


[2] OCTET 


STRING OPTIONAL, 


— Format 


as per 


RFC 2327 [7] 




— Clause 


6.3 describes when the mediaAttributes shall be present 


encrypt ionKey 




[3] OCTET 


STRING OPTIONAL, 


— Format 


as per 


RFC 2327 [7] 




sessionName 




[4] OCTET 


STRING OPTIONAL, 


— Format 


as per 


RFC 2327 [7] 




sessionlnfo 




[5] OCTET 


STRING OPTIONAL, 


— Format 


as per 


RFC 2327 [7] 




copyOfSDPMessage 


[6] OCTET 


STRING OPTIONAL, 


— Format 


as per 


RFC 2327 [7] 




frameType 




[7] Frame! 


ype OPTIONAL 


— Populated if one or more protocol layers are missing from CC data 


— May be 

} 


omitted if all heade 


rs are present . 



InformationAppliesTo : : = SEQUENCE 

— Identifies the PDUs to which a piece of supplementary information applies 
{ 

payloadDirection [0] PayloadDirection, 

— The direction of the traffic to which this info applies 
cCLinkID [1] INTEGER (0.. 65535) OPTIONAL, 

— If there are multiple CCLinks, this field states CCLink to which this info applies 
firstPDUNumber [2] INTEGER ( .. 4294967295 ) OPTIONAL, 

— The supplementary info applies to all PDUs with this sequence number and above 



FrameType 


: : = ENUMERATED 




ipFrame ( ) , 






— 


All headers 


are 


present 


udpFrame ( 1 ) , 






— 


IP header is 


missing 


rtpFrame (2) , 






— 


UDP and IP h 


eaders are missing 


audioFrame ( 3 ) , 






} 


All headers 


are 


missing 
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Description of the Pstnlsdn CC 



PstnlsdnCC ::= SEQUENCE 




{ 

pstnlsdnCCObjId [0] RELATIVE-OID, 




pstnlsdnCCContents [1] OCTET STRING, 




— See clause 6.2 for definition of format of Pstnlsdn CC 




cCLinkID [2] INTEGER (0.. 65535) OPTIONAL, 




— Shall be present if multiple CCLinks are used (see clause 

} 


6.3.4) 



END — end of PstnlsdnPDU 
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